QRZ! Ham Radio 11

home *** CD-ROM | disk | FTP | other *** search

/ QRZ! Ham Radio 11 / QRZ Ham Radio Callsign Database - Volume 11.iso / files / demos / pkgoldtd.exe / DOCFILES.EXE / VER9.DOC < prev

Wrap

Text File | 1994-04-05 | 37.7 KB | 884 lines

VERSION 9 NEW FEATURES Excerpt from "Performance Software" -- GOLD Software User Manual Copyright (C)1993,94 by InterFlex Systems Design Corporation All Rights Reserved Quick Summary: ALL For all users, GOLD (Pk, Ka, dsp, etc) adds the ability for you to setup your station as a callbook server, conference bridge, general file/information server, as well as support for ANSI pics, restartable file transfers, and more. AEA Ver 9 supports AEA's version 7 ROM additions, GUSERS, MYGATE and ARXTOR. AEA's rom for the PK-900 and dsp-2232 has a number of other changes that have fixed the pactor changeover bug. KAM Ver 9 supports G-TOR, the new mode from Kantronics that is about 4 times faster than Pactor, and about twice that of Clover, based on may on-the-air tests. The KAM version 7 rom also allows more NUMNODES (KaNode connects) -- well beyond the original 4 max. Lower the PBBS size, and raise NUMNODES. Ver 9 also displays ARQ link status information including Huffman compressed frame, link speed, error condition, etc. G-TOR tests were conducted by W0XI, WK5M (Phil Anderson, Karl Medcalf, both of Kantronics) and WA4EGT (Jeff Towle, InterFlex systems), transferring a 9718 byte file using G-TOR and Pactor. The file was transferred in each mode, under the same band conditions. The test was repeated over 100 times during the next two months. G-TOR was faster than Pactor in EVERY case, and averaged about 3-times faster. InterFlex Systems program, KaGOLD w/Pactor fully supports G-TOR mode, as well as Pactor, Amtor, RTTY, Morse, split screen, multi-connect, ANSI graphics, command files, conference mode, and much more. VERSION NUMBERS -- ALL PROGRAMS NOW VERSION 9 Starting with the 1994 release of PkGOLD and KaGOLD, version numbers are now consistent across different GOLD programs. This is a result of bringing all versions up to the same set of features. Version 9 represents a significant departure from the earlier versions of GOLD software. Commands from remote stations are now allowed, two screen modes are supported for every session- - the normal text character screen and a new ANSI graphic screen -- direct interface to callsign databases (SAM, Buckmaster, QRZ) is supported, restartable file transfers, and improved operation in Windows and other multi- tasking environments, and support for CW announcements through ad-lib type sound cards. As you read the rest of this description, look for more about each of the following subjects: o Callbook Support for four (4) CD based systems, and the SAM disk-based callbook. Users can lookup callsign data, the program does lookups automatically, and remote users can request callsign data making the station a callbook server (if remote commands are enabled and the appropriate callbook cmd file exists). Callbooks supported include Amsoft CD, Buckmaster CD, QRZ CD, SAM CD, and SAM Disk based callbook. o ANSI Graphics supported on all sessions simultaneously. Pics are saved automatically if desired, and the program can "flip" to graphics mode automatically. No other program offers simultaneous, multiple ANSI picture receiving. o Restartable YAPP and GOLD transfers. YAPP-C is supported, and restartable transfers are done automatically, as the program determines if the remote station supports these features. Partially complete files have a text header that makes it easy to determine which files are only partially received. o Conferences can be started remotely, allowing your station to be a conference server. Users can switch conferences, start new conferences, and leave the conference and remain connected if desired. They can also send messages directly to other stations in the same or different conference. o Remote commands, including user defined commands in CMD files. This allows you to create a file server, ANSI pic server, radio mods server and more. The ability to create commands that remote users can issue opens a whole new set of outlets for for your programming creativity. o Morse messages can be directed to an Ad-Lib compatible sound card. Also, CW pitch can be set by the user, both user options are in the SETUP area. o Network View lines now show headers in low-video, and text in high-video, making it easier to distinguish headers from text. This is done automatically. Callbook Support If you have AmSoft, BuckMaster, QRZ, or SAM (disk or CD-based) callbook, the program will access these automatically, as well as allow other users to lookup callsign data through your system. To activate the support, use [Alt-S], then Setup, then Callbook. SAM Callbook First, find and load the SAMAPI (SAM Application Programmers Interface). The SAM callbook access requires this SAMAPI program. It is included with SAM, possibly in a subdirectory of one of the SAM disks. To load SAMAPI from the GOLD directory you might type: C:\SAM\SAMAPI C:\SAM For Disk based Version C:\SAM\SAMAPICD S:\SAMCDDAT C:\SAM For CD ROM version If this does not load SAMAPI, check your SAM disks for SAMAPI and copy it to the SAM subdirectory. The second parameter in this command is the "Path" to the actual dataset. If you wish, make up a batch file to run GOLD and put this command before the KAGOLD or PKGOLD command. To unload SAMAPI from memory: C:\SAM\SAMAPI /R (or /UNLOAD depending on version of SAM) While in SETUP (see above) select SAM as your callbook type if this is the only callbook you plan to use. If you also have CD ROM callbooks, indicate that you have both SAM and CD callbooks. The program will search for callbook data in the following order: CD based calldata first, then the SAMAPI or SAMAPICD. CD Callbook -- Buckmaster, AmSoft and QRZ In Setup, select CD ROM callbook data. If you also have SAM, select CD ROM and SAM. The search for callbooks is described above. The reason we don't choose the and by default is to save the time required to check for the SAMAPI if it will never be on your system. We use the index files directly from the QRZ disk, but on the Buckmaster disk, we create a unique index file for each version of Buckmaster. This may take up to 10 minutes the first time you use the Buckmaster option. Local use of the Callbook You can access the callbook using [Alt-I] then enter a callsign. You can also send callbook data to a session using: SENDCALL <callsign> [more callsigns] [F10] This causes the program to access the callbook for each callsign in the list (one or more) and produce a "mailing label" format for each callsign, sending it to the current session (packet, amtor, pactor, etc). Last, if you are using [Alt-E] to edit the logbook entry for the callsign showing in the banner (a connected station), you can then use [F9] to look up the callsign in your on-line callbook. Callbook Server -- Remote Access If you have enabled remote commands on the [Alt-Z] menu, a remote user can type //CALL WA4EGT or even a log list of callsigns separated by spaces or commas, to request callbook information from your station. How does this work? The answer is simple (we think it is anyway). CALL is the name of a CMD file. Here is what CALL.CMD contains: * Contents of CALL.CMD (this is a comment) CALLBOOK @0 * Use zero not the letter O The command SENDCALL <callsign list> is a command in GOLD just like other TNC commands, and can be entered in a CMD file as above. The @0 (commercial "AT" sign followed by zero) is filled in with the string of characters supplied by the user who issued the CALL command. This means you can change the //CALL command to some other command, like //LOOKUP <callsign> if you wish. All you need to do is change the name of the file call.cmd to lookup.cmd and inform users that the new command name is lookup. Changing the names of this and other CMD files may introduce a lot of confusion. Conference Bridge Server If you have enabled remote commands in the [Alt-Z] menu, another station can connect to your station and join a conference without your assistance. This means that your station can be an unattended conference bridge or conference server. A remote user can connect and issue the following commands: //WHO To list stations & conferences //JOIN A To Join or create conference A //OFF Exit conference, remain connected //BYE Exit conference and disconnect //[call] text Send text msg to [call] The last command allows a conferenced station to send a message to another conferenced station directly. If N6WIK and WA4EGT are both connected, the following: //N6WIK Let's start Conf C, type //JOIN C would send the message to N6WIK only. Users can log //OFF a conference, ask //WHO else is connected, and create a new conference with //JOIN C or any letter up to J. Remote CMD files Users who connect to your station can issue 1 to 8 letter commands that you create through the use of command files. A command file is a file in the directory cmdfiles off the GOLD directory. It must have a cmd extension, and can contain any of the following kinds of lines: Comments: A line beginning with an asterisk (*) is a comment and is ignored. Message: A line beginning with a quote (") is sent to the station who issued the command Commands: TNC commands, or other "pseudo" commands that can also be run from command line with [F10] Most of the pseudo commands would not be issued directly by you, but would be put into CMD files for use in developing commands that remote users will find helpful. CMD file layout In the CMDFILES directory (which must be a subdirectory of the GOLD directory) you will create one or more files with .CMD extensions. A simple collection of 4 files might be as follows: CMD File #1 * Help.cmd file contents (used to list other commands) " ?NAME, you may use any of the following commands " note: some may provide additional help " " //WHO To list who else is connected " //CALL ?MYCALL Information about ?MYCALL " //CALL ?CALL Callbook information about yourself " //HFPARMS Help about HF-Packet Parameters " //LISTMODS List of Radio Modification files " << END OF HELP >> CMD File #2 * LISTMODS.CMD file " ?NAME, here is a list of MOD files SENDDIR S:\MODS\*.MOD " Note: Use //GETMOD <filename> to get a mod file " << END OF LISTMODS >> CMD File #3 * GETMOD.CMD file SENDTEXT S:\MODS\(@0) " << END OF RADIO MOD >> CMD File #4 * Call.CMD file -- returns callsign data SENDCALL @0 These examples show a number of features built into the CMD file processing. First, the use of the comment line to show the file name. You can document your CMD files using the asterisk (*) comment line, and it is a good idea to make liberal use of comments. The use of the Quoted text line, the (") quote mark signals GOLD to send the text to the remote user. A good way to tell them what is coming, and notice at the end of each file, we've put a line to clearly indicate to the user that the command file is finished. The senddir command (described below) sends a directory, and can use "wildcards" for the directory mask, just like DOS. This usage gives a directory of all files in the S: drive MODS directory. The sendtext command is used to send a prepared text file, in this case a radio modification file that resides on drive S: (the QRZ CD ROM for example). The (@0) is a special case of the user supplied substitution string. It removes any path information from the user parameter, leaving only a file name (if any). The last file is the CALL command file, and contains only the pseudo command SENDCALL followed by the user parameter string. It will perform the Callsign lookup function on the string (one or more callsigns) supplied by the remote user. Remote user parameters When a user sends a // command, the program looks after the // for a valid CMD file name. If a match is found, the line is processed as a command. The remote user can include a parameter, like a file name or directory name, or both. In the CALL.CMD file example, the parameter @0 is used. If multiple parameters (words separated by spaces) are passed to the CMD file processor, you can use @1 @2 @3 etc. to identify each word separately, which is useful for DOS batch file processing. A CMD file can use the EXECDOS command to pass user parameters to a batch file as follows: EXECDOS DOSPROG @0 When the CMD file processor sees this, the DOS shell is invoked, the program or batch file called DOSPROG is run, and the parameter @0 is passed to the spawned process as a single parameter string, as though typed at the DOS command prompt. Note: The "at" sign (@) is similar to the percent (%) sign used in DOS Batch files. The @0 is the entire user string, and the @1 through @9 are the individual words (parsed out of the string) in the @0 string. CMD file functions Senddir [path] [filespec] This cmd file function will send the directory of the default upload path if no parameters are passed to it. If you include a path, the directory of the files in that path are sent to the user connected that issued a CMD filename with a SENDDIR. Examples: Senddir S:\MODS\*.MOD Senddir S:\@1 The first example simply sends a directory of all files matching the *.MOD filespec. Similar to the DOS directory command and how it proc esses this kind of filespec (file specification). The second Senddir takes the first parameter (or the only one) provided by the remote user and substitutes it for the @1. A remote user typing a command followed by mods\IC*.* will get all files that match S:\mods\IC*.* due to the substitution that follows the S:\ in the above example. Sendyapp [path] [filename] This command sends a filename using YAPP protocol. The file name can be provided as "hard coded" or it can use the substituted parameter approach, similar to the SENDDIR above. Examples: Sendyapp S:\mods\ft990.mod Sendyapp s:\@1 The first example sends one file, that's it! No options. The second example allows the remote user to contribute a path and filename to request. Sendgold [path] [filename] This is a variant of binary file transfer using YAPP, only in this example, the transfer protocol is the GOLD protocol, which allows you and the remote station to continue conversing on the session/stream. This is only honored if the remote station is identified as a GOLD user by the automatic exchange process. Sendbin [path] [filename] This method is like SENDYAPP and SENDGOLD with another layer of automation -- it figures out whether to use YAPP or GOLD protocol depending on whether the remote station is a GOLD user or not. If you want to send using GOLD protocol to any GOLD user, and to use YAPP with all other stations, then sendbin is the right command. Sendtext [path] [filename] This sends a file as plain ascii, no special protocol (like yapp or gold) and cannot be used to send binary files, like programs that have .COM or .EXE, or .ZIP extensions (to name a few). Use this method to send a MOD (radio modification) or some other file of text data. SendRaw [path] [filename] Some files, in particular ANSI graphic or "pic" files, and specially formatted text files such as M.A.R.S. messages created with programs that produce multiple Linefeeds rather than multiple CRLF sequences, must be sent with the Raw send capability of PK and KAGOLD. This command can be used in CMD files that need to use this raw send capability. It is this command, coupled with SendText and SendDir that can make your station into an ANSI Picture "Server" and allow remote users to receive ANSI graphics in an unattended mode. Recvyapp This command puts the current session into a YAPP receive mode. It will be ready for a yapp transfer from the other station. It does not require any parameters, and the files will be put into the default download directory that is specified as the "download path" in the setup area (under file transfers). There is no need for a "recvgold" because this is handled automatically when GOLD gets a "here comes a file" type packet. SENDCALL [callsign or list of callsigns or @0] This was described above in the example for the //call <callsign> command file. It will access whatever callbook it can find and produce the callbook information, sending it to the remote station. The use of @0 means the entire line of text (several callsigns) will be passed to the SENDCALL routine, with several callsign lookups. You can use this command to send calldata to a friend: try SENDCALL W1AW [F10]. Conference Commands The following commands are specific to the conference only, and are built-in, internal commands read directly by the software and processed immediately. While they look like the other commands, using the //cmdname format, they are unique to the conference processing. //who Display a list of Who is connected, and what conferences are in progress, if any, with letter identifiers. You can JOIN any conference. Outside of the conference, a user typing //who can access a WHO.CMD file to perform a similar function. The file might look as follows: *who.cmd contents (or name it USERS.CMD) "At ?Time SENDWHO Understand that the //who command issued by a station in conference will be processed by the internal "who" command parser, and will list only the connected stations. Outside of the conference, the same //who command is processed by the CMD file processor, using the SENDWHO tnc pseudo command. You can issue SENDWHO locally, as you can with any TNC or Pseudo-TNC command, type it and push [F10]. //name [yourname] A conference member may fill in his/her name, or change his/her name that is associated with the callsign. //Join <conference letter> This causes the station to be "joined" into a conference, or to create a conference with the letter chosen. //<callsign> <text to send to callsign> Send a string of text directory to the callsign typed out. Callsign must include the station's SSID if that is how it appears in the conference. //Off Exit from the conference, but remain connected to the station. Useful to issue other remote commands, get files, etc. Here is another conference command that can have a counterpart outside of the conference. You could create an OFF.CMD file, or LOGOFF.CMD file with the following format: * OFF or LOGOFF.CMD file layout "73 from ?MYCALL -- OFF at ?DATE ?TIME DISC //Bye Exit from conference, and disconnect. Again, you could create a BYD.CMD with a DISC command in it (like the OFF command) for use outside the conference. Advanced CMD file examples You can create some interesting CMD files, and with some planning, make your station into a resource for radio mods, information files, propagation forecasts, just about any collection of information you wish. Here are a few CMD files with a brief explanation of what each does. Use them as a prototype for making your own CMD files. * This sends a list of my brg files (first line -- a comment) "Here is a list of my BRG files: execdos dir/w brgfiles\*.brg > upload\brgfiles.lst sendtext brgfiles.lst "<< END OF LIST >> "Use //GETBRG filename to have a file sent back to you The second line uses the Quote command to send the text Here is a list of my BRG files to the remote user. The next line is more interesting. It shells to DOS with EXECDOS, does a DOS directory (with /W meaning wide) of all files in the BRGFILES subdirectory with the BRG extension, redirecting the output of the DIR command to the upload directory, to a file called BRGFILES.LST. Finally, the SENDTEXT command is used to send the list of files. A couple of things to note: First, all directory references begin with the GOLD directory as the default directory. The DIR command, if issued from the GOLD directory, need only refer to BRGFILES subdirectory to cause the output to be redirected there. It is not necessary to fully specify the directory name. That means, for example, you can write these relatively benign, generic CMD files that will work on ANY drive letter, and can be used no matter what name was given to the main GOLD directory. Second, this example demonstrates the power of CMD files coupled with the EXECDOS command. Here is what the GETBRG.CMD file might look like, to allow users to request one of your BRG files. * GETBRG CMD file, used to get a BRG file "Here is a copy of "@0" sendtext brgfiles\(@0) Radio Modifications "server" example Here is group of files that provides radio modifications lists. *Helpmod.cmd file -- explains how to use MODS list "To get a list of MODS, or a partial listing type "//LISTMODS for all MODS "//LISTMODS FT all mods starting with FT "//LISTMODS TS4 TS430, TS440, TS450, etc This first HELPMOD.CMD file is straightforward. It uses the quote character to send help information to the remote station that typed the command //HELPMOD. This next file does the LISTMODS command from a remote user. * listmods.CMD, shows mods from QRZ dir senddir s:\mods\@0*.mod "Use //GETMOD <Modfilename> to get file Line 1 is a comment line, it begins with an asterisk (*). Line 2 sends a directory from the S:\MODS directory using the remote request, and adding the asterisk followed by .MOD. If the user were to type //GETMOD FT the @0*.MOD would become FT*.MOD which will give a directory of all files beginning with FT and having a .MOD extension. The last line tells the user how to actually retrieve one of the mod files. The getmod.cmd file might look like this: * Getmod.cmd file, sends the mod requested //sendtext s:\mods\@0 "<<end of mod file>> In this example, the user would have to type the exact filename, including the .mod extension. Calling a batch file example This last CMD file example shows how to call a batch file using EXECDOS and how to refer to the GOLD directory itself. The objective here is to call the Buckmaster ICALL program and request the extra station information that comes along when you use the /S option (supported in the BuckMaster Callbook CD). The user will be told to type //LOCATE <callsign>, and LOCATE.CMD is the file we need to create. In addition, a batch file is needed that does the actual work of calling ICALL once the program shells to DOS and gives control to the batch file. Here is the listing of LOCATE.CMD: * LOCATE.CMD for locating (Lat/Lon) by Callsign * Usage: * //LOCATE <callsign list> "Processing call(s).... execdos ic_loc @0 * This next line is tricky, the only way to send from the GOLD * directory itself. This is a DOS issue, where dot (.) is the * current directory. The backslash is needed to separate the * dot from the filename. sendtext .\location.dat "<< END OF LIST >> This file has a lot of comments in it, a good idea when writing your own CMD files that others may use, or that you will maintain. The two highlighted lines do the work. First, the execdos command calls ic_loc.bat, a file located in the main GOLD directory. It passes the parameter(s) that were typed by the user by referring to the @0. The IC_LOC.BAT file will be shown in a moment. The next highlighted command uses the DOS syntax ".\" which is way to refer to the default directory. Without a directory specified like this, GOLD reverts to the default directory for sending files, namely the upload directory. We want to perform the callsign and station information lookup in the GOLD directory. Here is what IC_LOC.BAT has in it: @echo off rem Put this BAT file into the GOLD directory IF %1x==x goto Nocall S:\ICALL S: %1 /S > location.dat edlin location.dat < fixdata.cmd > nul GOTO ENDBAT :NOCALL ECHO Need a callsign to lookup! > location.dat :ENDBAT This batch file takes the commands from the execdos command in the locate.cmd file that were typed by the remote user. The callsigns requested have traveled through the network, to GOLD, to the CMD file in the @0, to the batch file and DOS sees the parameter as %1. The only twists here the redirection of the output of ICALL to location.dat, and the editing of location.dat using the DOS line editing program EDLIN. We pass EDLIN a filename to edit, and tell it what to do in the file FIXDATA.CMD. The confusion about CMD files here is evident, but this CMD file has commands to the EDLIN editor. Here is what is in FIXDATA.CMD: 1,3d e These EDLIN commands simply delete lines 1 to 3 of the resulting buckmaster icall output, and then exit the editor. You can learn more about using the EDLIN editor, and passing commands to it by referring to your DOS manuals. The idea of presenting these examples is to give you an idea of the power of the the new GOLD command file processing, especially when combined with batch files. ANSI Pics KaGOLD and PkGOLD are the only programs available that can capture and display multiple ANSI sequences simultaneously, capture them automatically, and on dual port units, capture ANSI graphics on both ports simultaneously. The only HF mode that is capable of supporting ANSI, without causing errors, is PACTOR. American National Standards Institute defines several "escape sequences" that involve cursor positioning, color setting, screen clearing, etc., and with the GOLD ANSI capabilities, you can view these ANSI "Picture" or "Graphic" files. An ANSI sequence is easily recognized by its use of the [ESC] character, which prints as a left arrow, and the opening square bracket. If you see in some text, this is very likely the beginning of an "escape sequence" that contains cursor position, color, or other information for an ANSI interpreter. When an ANSI "picture" is received Every "session" has its own memory buffer, allocated and deallocated automatically. When an ANSI picture is detected, a second buffer is created for the session, and it becomes the scratch-pad or canvass to draw the resulting ANSI picture. This buffer is only created when the software detects the need for it. Therefore, as you read the next few sections about ANSI pictures, realize that [Alt-G] the keystroke used to "flip" to and from the graphic will only work if there is or was a graphic for this session. The purpose here is to save computer memory, another aspect of dynamic memory management that is built into GOLD software. If you use [Alt-G] and nothing happens, then no ANSI picture is available for display on the active session. Manual Display [Alt-G] As explained above, the ANSI screen is not always available. You can use [Alt-G] to see the ANSI graphic only if one exists. [Alt-G] is a toggle, switching between the graphic (if any) and the "normal" text screen. Auto-Capture By default, ANSI "pictures" are captured into the ANSFILES directory. Automatically captured "pictures" are given file names as follows: GOLDnnnn.ANS where nnnn is a number from 0001 to 9999. If you collect more than 9999 pictures, the file will be named GOLnnnnn.ANS, dropping the "D" in GOLD and using 5 digits to express the picture number. Hopefully, you will review the files occasionally, and rename them to something more reasonable, like BART.ANS, or TRAIN.ANS. You can turn this feature OFF if you wish, in the Setup area under Screen Settings. Auto-Flip The program defaults to "flipping" to the graphics screen when incoming ANSI sequences are detected. You can change this to OFF in the Screen Settings area under Setup (as above). When the screen flips to graphics, you can always use [Alt-G] to return to the regular session screen and see the ANSI sequences in their raw, uninterpreted form. If you turn Auto- Flip OFF, you will always have to use [Alt-G] to see ANSI pics. The ON setting is probably the most useful, but some users may want to avoid flipping to ansi graphics and do everything manually. Reviewing ANSI pics A program called SHOW.EXE may be in the ANSFILES subdirectory. It is also available on the InterFlex Systems BBS. Use this program to review ANSI graphics by typing the following command: SHOW sample.ans (or whatever the filename is) A second method is to have ANSI.SYS loaded from your CONFIG.SYS file. If ANSI.SYS is active, all you need to do is TYPE the file and let the ANSI interpreter display the graphic. ANSI graphics with animation do not show very well, if at all, using this approach, but it is a quick way to review pictures. The command would be: TYPE sample.ans (assuming this file exists) Other programs can be used to edit and create your own ANSI pics. Creating ANSI Pics There is at least one program available on the InterFlex Systems BBS that can be used to create ANSI "graphics" files. It is TheDraw. You can download the zip file called TDRAW450.ZIP, extract the files, and take a shot at creating your own ANSI files. Here is the most important caveat: when you write your files, or save them, set the right margin, or maximum line length to 75, or some length below 80 characters. Using 75 allows others to copy/paste the ANSI sequences. Restartable File Transfers In Version 9, file transfers using a "protocol" like YAPP-C or GOLD are restartable. Text files and raw send (for ANSI pics) are "one way" type transfers and have no "protocol" and do not always result in creating a file on the other user's system. GOLD and YAPP do create files on the receiving station's computer. If the transfer is stopped, or aborted, the partially received file is saved with a special header that allows the transfer to resume, or restart rather than start from the beginning. This saves time. GOLD protocol On the [F6] transfer menu, sending or receiving files automatically supports restartable transfers (see above). With earlier versions of PkGOLD and KaGOLD, the restartable transfer is not supported, but you will still be able to send and receive files while connected to some earlier versions of PkGOLD and KaGOLD. YAPP-C protocol The YAPP (yet another packet program) system for sending and receiving files has been extended to YAPP-C, with and without restarting. With PkGOLD and KaGOLD, this is entirely transparent. If the remote station supports restarting, your station will handle it automatically. If not, again the software "knows" and handles things automatically. Just transfer files with YAPP to a local BBS or other user, and if YAPP-C or restartable YAPP is supported, your station will automatically comply with the newer protocol. Setting Alt-Messages You can use the Setup menu, Alt-n message selection to alter your one-line Alt-n messages (alt-0 through alt-9) or use a new feature in this latest version, the setalt <n|p><0..9> text... pseudo tnc commands. The syntax of this new command is the setalt command, the alt-n message you want to change, and the text string. The <n|p> means "Non-packet OR packet" and the number 0 through 9 must be included to identify which Alt-n message to change. In any of your TNC or CMD files, you can put one or more of these new commands. You can also type the command from the command line to change an alt-n message. For example: setalt p5 My QTH is Laguna Niguel, CA [F10] setalt n1 ?call de ?mycall [F10] You can include any number of setalt pseudo commands in your tnc or command (cmd) files. Be sure the strings do not exceed about 100 characters. Even better, do not exceed about 65 characters so that you can read the entire line when you hit the Alt-n. Hints for usage: Some users have suggested that we have a set of Alt-n messages for each mode, not just packet and non-packet. This new feature allows you to create a set for each of the non- packet modes, and put them into a tnc file that also calls up the mode. For example, an AMTOR.TNC file might contain several setalt messages for usage in amtor. It might be good as well to create a tnc file with a collection of default alt-n messages. RESETALT.TNC would be a good name. Special Connect BRG files You can do some new things with connect files. If you have enabled the sending of "connect.brg" when a station connects (do this in the Setup menu, under Alt-n messages) you will have a few new options for naming the files. The program will look for any one of three files. First, a file with the same name as the callsign of the connecting station. Second, a file with the name "CO-xxx.brg" where "xxx" is the name of the port (the name you give the port on dual-port tncs). For example, create a short file called CO-HF.BRG and a larger CO-VHF.BRG file. Then, when a station connects on HF, the HF connect text file will be sent. This allows you to send short files on HF, and longer files on VHF. Third, the program looks for CONNECT.BRG, and sends it if it cannot find another file to use. If you create CO-HF.BRG, and K8TNK.BRG, and have the standard CONNECT.BRG in the BRGFILES directory, here is what would be sent under each condition: K8TNK connects on either HF or VHF, send K8TNK.BRG WA2VSM connects on HF, send CO-HF.BRG WB8TKE connects on VHF, send CONNECT.BRG Hints for usage: You can use the callsign.brg approach to leave a message for another station. It will be sent every time the station connects until you delete that file, but you may have a message that is intended as a reminder for another station. Changes from Prior Versions In addition to the major changes explained in this chapter, there are several minor adjustments that will improve the operation of the program. For example, the logging system uses a B-tree index rather than a hashing index. This is a technical matter, but the new system is faster, and has much larger capacity and is much faster. The monitor screen has been modified to show information frames with a bright color attribute, with headers in a dim or normal brightness. The on-screen clock uses a different technology that improves reliability of the program when operating in a multitasking environment. The technology for determining when to unkey the transmitter in the non-packet modes has been beefed up, to assure that unkeying occurs as quickly as possible when the buffer empties. The way the program does overlays is improved, to be faster and more reliable on systems that are slow to switch between real and protected mode. The program handles more types of nodes, including TEXNET which uses the commercial at sign (@) in certain parts of the connect commands. Other changes to version 9 are the result of the months of beta testing that this program has been through. When other users ask what is new about Version 9, tell them the major new additions, which are (1) Callbook support for 3 CD ROM based systems, and SAM; (2) Support for ANSI graphics, on all sessions, simultaneously; (3) Conference server mode, with remote started, and changed conferences; (4) Remote command files that are user defined and able to send textfiles, directories, and start binary file transfers; and (5) File transfers are now restartable with both YAPP-C, and GOLD protocols supported. Some changes may be more useful than others to certain users, but we hope that you find these additions fun and easy to use. <<END>>